home *** CD-ROM | disk | FTP | other *** search
PPPPMMMMNNNNSSSS((((4444)))) PPPPMMMMNNNNSSSS((((4444)))) NNNNAAAAMMMMEEEE ppppmmmmnnnnssss - the performance metrics name space SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS $_P_C_P__V_A_R__D_I_R/_p_m_n_s DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN When using the Performance Metrics Programming Interface (PMAPI) of the Performance Co-Pilot (PCP), performance metrics are identified by an external name in a hierarchic Performance Metrics Name Space (PMNS), and an internal identifier, the Performance Metric Identifier (PMID). A PMNS specifies the association between a metric's name and its PMID. A PMNS is defined on one or more ASCII source files, that may be compiled using ppppmmmmnnnnssssccccoooommmmpppp(1) to produce a binary PMNS. Note that ppppmmmmnnnnssssccccoooommmmpppp(1) is normally invoked from the $_P_C_P__V_A_R__D_I_R/_p_m_n_s/_R_e_b_u_i_l_d script if necessary when ppppmmmmccccdddd(1) is started. Loading of a PMNS is done by calling ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) which silently tolerates either the ASCII or binary formats. Alternatively, ppppmmmmLLLLooooaaaaddddAAAASSSSCCCCIIIIIIIINNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) may be used to load just the ASCII format. If the binary format is used, no checking is performed for aliasing in which multiple names in the PMNS are associated with a single PMID. If the ASCII format is to be used, duplicate PMIDs are not allowed, although ppppmmmmLLLLooooaaaaddddAAAASSSSCCCCIIIIIIIINNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) provides an alternative interface with user- defined control over the processing of duplicate PMIDs in an ASCII format PMNS. The external ASCII format for a PMNS conforms to the syntax and semantics described in the following sections. There is one default PMNS in the files below $_P_C_P__V_A_R__D_I_R/_p_m_n_s, although users and application developers are free to create and use alternate PMNS's. For an example of this, see the PCP Tutorial in $_P_C_P__D_E_M_O_S__D_I_R/_T_u_t_o_r_i_a_l. Although an application can call ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3), normally this is only done directly for the ----nnnn command line option where an explicit root PMNS file is specified. Since PCP version 2 uses a distributed PMNS (see below), an application can extract PMNS information from a host's PMCD or an archive. If the PMNS source (pmcd or archive) is version 1 (see PPPPCCCCPPPPIIIInnnnttttrrrroooo(1)), however, then the local PMNS will be loaded using the path specified by the environment variable PPPPMMMMNNNNSSSS____DDDDEEEEFFFFAAAAUUUULLLLTTTT. DDDDIIIISSSSTTTTRRRRIIIIBBBBUUUUTTTTEEEEDDDD PPPPMMMMNNNNSSSS In PCP version 1, the PMNS functions in the API all operated on a PMNS loaded locally from a file. Since PCP version 2, however, PMNS functions may get the PMNS information remotely from a PMCD or directly from the meta data of an archive. We call this a distributed PMNS. It has the advantage that the PMNS should always match the source of the metrics. For example, in PCP version 1, if one wanted to access a remote PMCD which had an agent installed which one didn't have installed locally, PPPPaaaaggggeeee 1111 PPPPMMMMNNNNSSSS((((4444)))) PPPPMMMMNNNNSSSS((((4444)))) then the local PMNS had to be updated just for that agent. This is no longer the case. In order to be compatible with version 1 PMCDs and version 1 archives (see PPPPCCCCPPPPIIIInnnnttttrrrroooo(1)), the local PMNS (PPPPMMMMNNNNSSSS____DDDDEEEEFFFFAAAAUUUULLLLTTTT) is automatically loaded as was done previously in PCP version 1. From an API level, there has been minimal changes. The main change is that if an application wants to use the distributed PMNS then it should nnnnooootttt call ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) or ppppmmmmLLLLooooaaaaddddAAAASSSSCCCCIIIIIIIINNNNaaaammmmeeeeSSSSppppaaaacccceeee(3). Doing so will load the local PMNS as specified above. Not calling these functions would previously (in PCP version 1) cause an error when trying to access the PMNS but now (in PCP version 2) it will force the PMNS functions to look at the metrics source for their information. PPPPRRRROOOOCCCCEEEESSSSSSSSIIIINNNNGGGG FFFFRRRRAAAAMMMMEEEEWWWWOOOORRRRKKKK The PMNS specification is initially passed through ccccpppppppp(1). This means the following facilities may be used in the specification + C-style comments + #_i_n_c_l_u_d_e directives + #_d_e_f_i_n_e directives and macro substitution + conditional processing via #_i_f ... #_e_n_d_i_f, etc. When ccccpppppppp(1) is executed, the ``standard'' include directories are the current directory and $_P_C_P__V_A_R__D_I_R/_p_m_n_s. SSSSYYYYNNNNTTTTAAAAXXXX The general syntax for a non-leaf node in the PMNS is as follows pathanme { name [pmid] ... } Where _p_a_t_h_n_a_m_e is the full pathname from the root of the PMNS to this non-leaf node, with each component in the pathname separated by a ``.''. The root node for the PMNS must have the special name ``root'', but the common prefix ``root.'' must be omitted from all pathnames. Each component in the pathname must begin with an alphabetic character, and be followed by zero more characters drawn from the alphabetics, the digits and the underscore ``_'') character. For alphabetic characters in a pathname component, upper and lower case are distinguished. Non-leaf nodes in the PMNS may be defined in any order. The descendent nodes are defined by the set of _n_a_m_e_s, relative to the _p_a_t_h_n_a_m_e of their parent non-leaf node. For the descendent nodes, leaf nodes have a _p_m_i_d specification, non-leaf nodes do not. The syntax for PPPPaaaaggggeeee 2222 PPPPMMMMNNNNSSSS((((4444)))) PPPPMMMMNNNNSSSS((((4444)))) the _p_m_i_d specification has been chosen to help manage the allocation of PMIDs across disjoint and autonomous domains of administration and implementation. Each _p_m_i_d consists of 3 integer parts, separated by colons, e.g. 14:27:11. This hierarchic numbering scheme is intended to mirror the implementation hierarchy of performance metric domain, metrics cluster (data structure or operational similarity) and individual metric. In practice, the two leading components are likely to be macros in the PMNS specification source, and ccccpppppppp(1) will convert the macros to integers. These macros for the initial components of the _p_m_i_d are likely to be defined either in a standard include file, e.g. $_P_C_P__V_A_R__D_I_R/_p_m_n_s/_s_t_d_p_m_i_d, or in the current source file. The current allocation of the high-order (PMD or domain) component of PMIDs is as follows. ___________________________________ Range Allocation ___________________________________ 0 reserved ___________________________________ 1-31 SGI internal ___________________________________ 32-39 Oracle ___________________________________ 40-47 Sybase ___________________________________ 48-55 Informix ___________________________________ 60 Linux ___________________________________ 56-127 ISV Performance Metrics ___________________________________ 128-254 End-user applications ___________________________________ |||||||||||||||||| |||||||||||||||||| |||||||||||||||||| EEEEXXXXAAAAMMMMPPPPLLLLEEEE #define IRIX 1 root { network cpu } #define NETWORK 26 network { intrate IRIX:NETWORK:1 packetrate } network.packetrate { in IRIX:NETWORK:35 out IRIX:NETWORK:36 } PPPPaaaaggggeeee 3333 PPPPMMMMNNNNSSSS((((4444)))) PPPPMMMMNNNNSSSS((((4444)))) #define CPU 10 cpu { syscallrate IRIX:CPU:10 util } #define USER 20 #define KERNEL 21 #define IDLE 22 cpu.util { user IRIX:CPU:USER sys IRIX:CPU:KERNEL idle IRIX:CPU:IDLE } SSSSEEEEEEEE AAAALLLLSSSSOOOO PPPPCCCCPPPPIIIInnnnttttrrrroooo(1), ppppmmmmccccdddd(1), ppppmmmmnnnnssssccccoooommmmpppp(1), PPPPCCCCPPPPIIIInnnnttttrrrroooo(3), PPPPMMMMAAAAPPPPIIII(3), ppppmmmmEEEErrrrrrrrSSSSttttrrrr(3), ppppmmmmGGGGeeeettttCCCCoooonnnnffffiiiigggg(3), ppppmmmmLLLLooooaaaaddddAAAASSSSCCCCIIIIIIIINNNNaaaammmmeeeeSSSSppppaaaacccceeee(3), ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3), ppppccccpppp....ccccoooonnnnffff(4) and ppppccccpppp....eeeennnnvvvv(4). PPPPaaaaggggeeee 4444 
